RE: [-empyre-] building better list software
> point taken, jim. but one may have to start from the advantages of lists
> (because the disadvantages are well known by now).
are they? if one were to try to describe the top five problems with lists, i
wonder if there would be any concensus, and what sorts of problems people
would formulate? it isn't so clear to me, really.
but of course, yes, the advantages are important in such a discussion too:
usually discussion of tradeoffs and benefits/problems is inherant to such
discussion.
> why do lists still
> exist? because they are based on email and can be read offline, in your
> own time (and space).
i agree that their being email-based is important: everybody knows how to
use an email client and how to click the send/receive button.
> despite dsl and wireless the web is not ubiquious
> and perhaps never will. so possible improvements of lists should take
> this into account and not look at web applications.
>
> Best, Geert
it would be an important consideration in drawing up plans for better
listserv software, wouldn't it.
if there were a multiple-folder architecture, upon subscription to a list,
the person might be prompted to specify how they wanted the information to
be downloaded. for instance, the default might be 'download all folders'.
and the first time, it would download everything from the last few days, or
up to x messages or something like that. Non-default options could include
just downloading certain folders. Also, the option of treating it like a web
application might be advantageous for some, ie, just get the headers, not
the messages. newsreaders let you 'download next x messages'; could
generalize from that.
listservs; newsgroups; web forums: one would want to take the best of all
these things and make the architecture simply configurable to accomodate
different types of internet connections and preferences.
and if it were really well done, it would not simply take the best of what
already exists but would innovate beyond what already exists. and that would
involve addressing things like the top five or ten problems associated with
lists.
ja
http://vispo.com
This archive was generated by a fusion of
Pipermail 0.09 (Mailman edition) and
MHonArc 2.6.8.